	Autonomous exploration and SLAM are topics that are still being researched. Common algorithms  all deal with uncertanties introduced by the robots hardware like wheel slippage or sensor noise problem specific to the lower-cost models. 
	Still a lot of coding time and effort is still needed for the filtering of input data, in order to reduce the errors due to noise in the sensors and odometry. This means the SLAM algorithm are still  hardware dependent and any shortcomings of the robot's components still have a huge impact, despite the fact SLAM algorithms take into account uncertainties.
	
	Using TinySlam instead of GraphSlam means there was a trade off in the resulting map accuracy, in the usage of computing resources and also in code complexity.
	Computing power is still a constraint for SLAM algorithms, because running on mobile platforms means that in order to extend battery life a lower amount of resources like processor cycles and memory are used. The TinySlam code is only a couple hundred lines long, making it easy to understand and fast but it is still challenging to run it in realtime.
	Errors in laser filtering means obstacles are falsely detected or sometimes obstacles are not detected, and the resulting open space interferes with the navigation.
	GraphSlam uses a scan-matching algorithm thus improves its accuracy by reducing the uncertainty in movement and also by storing a history of the map and being able to perform loop closure.
	
	We encountered several problems with the ROS navigation package, finding it difficult to implement without modifications. Also, being a black box had its disadvantages when trying to modify it in order to incorporate it into our program, but the most important issue is the steering limitation to 45 degrees, meaning that the usual algorithms should have incorporated additional steps to accommodate this. Due to these facts, we successfully implemented our own navigation, using a topology-based A* search.
	